GitHub Projectsを使った（プロダクト/ スプリント）バックログ管理 #スクラム

Kyo

2024.04.12

こんにちはCX事業本部のKyoです。

スクラムマスターを担当していたプロジェクトから離れることになったので、備忘録を兼ねて（プロダクト/ スプリント）バックログ管理の方法を書き残しておこうと思います。なお運用実績は半年ほどです。

背景

プロジェクトの参画時、開発手法として独自定義のアジャイルが採用されており、以下のような課題がありました。

PBIの優先順位が不明確で、プランニングが困難
新規追加されたPBIの内容をチーム全員が把握できていない
- そもそも追加されたこと自体に気づきにくい
スプリントのゴールが分かりづらい
- 数週間連続で同じPBIが残り続けるなども
- プロダクトバックログ(相当のもの)とスプリントバックログ(相当のもの)が一体化している

これらを解決するために、開発手法をスクラムへ移行し、バックログの管理の方法を見直しました。なお、移行にあたってはメンタルモデルを獲得するため、先行してスクラムガイドの読書会を実施しています。

GitHub Projectsによるバックログの管理

概要

GitHub Projectsで4つのビュー（New Item、Product Backlog、Sprint Backlog、Completed）を作りました。Sprint Backlog以外はテーブル形式で、以下のカラムを使い分けています。

カラム名	タイプ	概要
System	Single Select	システムの名前を選択します。
Title	Text	PBI名をユーザーストーリー形式で書きます。
Ready	Single Select	PBIの状態に合わせて以下の項目から選択します。・ Ready: PBIに着手できる状態・ NotReady: なんらかの条件がありPBIに着手できない状態・ Draft: PBIの本文を起票中・ Drop: 検討した結果、プロダクトバックログに追加しないことになったもの
Ready条件/備考	Text	Readyのカラムが"NotReady"の場合にReadyになるための条件を明記します。また必要に応じて備考を記入します。
Size	Single Select	PBIのサイズをフィボナッチ数(1, 2, 3, 5, 8…)で選択します。
★ Labels	Labels	PBIの種類を説明する任意のラベルを付けます。
Sprint	Single Select	"S1" といった形でスプリント番号を選択します。また、現スプリントで対象になっているものについては"this"を選択します。
★ Status	Single Select	Sprint Backlogでのみ利用。詳細は後述。

★ はGitHubによって作られるものです。

以降、ビュー名はアルファベットで表記します。

New Item

Product Backlog Item (PBI)候補の新アイテム一覧を表示します。新アイテムはリファインメントの度に確認され、Product Backlogへ移るため、本ビューは空が基本の状態となります。

クエリ

no:size -ready:"Drop"

Product Backlog

PBIの一覧を表示します。優先順位順に並んでおり、プロダクトオーナーの合意の下で並び替えを行うことができます。

クエリ

is:open -no:size  -ready:"Drop"

Sprint Backlog

今スプリントの対象となっているPBIとその進行状況を表示します。

クエリ

sprint:this

レーン概要

statusカラムの値ごとに整理されます。

TODO
- 進行中ではないアイテムが並ぶ
In Progress
- 進行中のアイテムが並ぶ
- WIPの制限
  - In Progressに置けるアイテムは1人1つまで
  - 別のアイテムに着手するときは着手済みであってもTODOに戻す
    - 参考: なぜWIPの制限が重要なのか
In Review
- レビュー待ちのアイテムが並ぶ
  - Pull Request (PR)等のレビュー依頼をしたらこのレーンに移動
  - レビューで修正依頼を受けたものに関してはIn ProgressもしくはTODOへ
DONE
- レビュー完了後のアイテムが並ぶ

Completed

完成したPBIをスプリント番号の降順で表示します。主に過去のPBIのふりかえり用です。

クエリ

is:closed -no:size  -ready:"Drop"

主な操作

PBI候補の新アイテムを登録する

When

いつでも

Who

だれでも

How

New Itemの「Start typing to…」左の+ボタンから登録します。

アイテムの実体はIssueです。タイトルはユーザーストーリー形式 (例: ゲストは記事に対してコメントを投稿できる) で書きます。本文についてはテンプレート(※)に従って記入します。

起票後、Size以外のカラムに内容を設定します。 ReadyカラムのラベルがNotReadyである場合はReady条件/備考を記入します。

この時点では新規PBIはNew Itemにのみ表示されProduct Backlogには表示されません。

※ テンプレートはIssue Templateで使っていました。以下に例を示します。

## 概要
<!-- このPBIにおける主要な課題や機能、及び期待される成果について簡潔に説明してください。-->

### 何をやるのか

### なぜやるのか

## 受入条件
<!-- このPBIを完了とするための条件をリスト形式で記載してください。受け入れ条件は状態として記載します。-->
- [ ] 受入条件1
- [ ] 受入条件2

## タスク
<!-- 開発者がこのPBIを達成するために必要なタスク（具体的な作業項目）をリスト形式で記載してください。-->
- [ ] タスク1
- [ ] タスク2

## その他
<!-- このPBIに関連するドキュメント、過去の類似したPBI、注記や備考などをここに記載してください。-->

新アイテムをPBIとしてProduct Backlogに追加する

When

リファインメント

Who

新アイテムの起票者
リファインメントのファシリテーター

How

起票者が新アイテムの概要を説明、チーム全員で Sizeカラムに適切なラベルを検討、妥当な値を設定します。 Sizeが設定されると、New Itemに表示されなくなり、Product Backlogに表示されます。

プロダクトオーナーが優先順位に合わせてProduct Backlogの中での位置を決定します。

スプリント対象のPBIをSprint Backlogに追加する

When

(原則) スプリントプランニング

Who

プランニングのファシリテーター

How

Product BacklogのSprintカラムにthisのラベルを設定します。これによってSprint Backlogに表示されます(Product Backlogにも表示されたままになります)。

なお、スプリントプランニング以外のタイミングでSprint Backlogにアイテムを追加した場合(差し込み)は通常のアイテム追加と区別するためにLablesにAdditionalを追加していました。

完成したPBIをProduct Backlogから非表示にする

When

スプリントレビューで対象PBIの完成判定が出た時

Who

スプリントレビューのファシリテーター

How

Product BacklogのSprintカラムをスプリント番号のラベル (例: S1)に変更します。これによってSprint Backlogに表示されなくなります。

PBIの実体であるIssueをクローズします。これによってProduct Backlogにも表示されなくなり、Completed に表示されるようになります。

利用イメージ

以下のように利用していました。

朝会 (リファインメント + デイリースクラム)

New Itemを確認
- あれば起票者が内容を共有
- チーム全員でサイズを見積り
- プロダクトオーナーがProduct Backlogの任意の位置へ
Product Backlogの優先順位に変化がないかの確認
Sprint Backlogを確認して、相談事のあるなしを確認

スプリントプランニング

プランニングに含めたいNew Itemがないかを確認
- 基本的には朝会で確認だが急ぎのものがあれば
Product Backlogの優先順位に変化がないかの確認
Product Backlogの上から順にSprintカラムにthisをつけていく
- いくつ取るかはチームのキャパシティ（可処分時間）と相談

セルフふりかえり

よかったポイント

元々の課題(背景参照)はどれも解決できた
- 実際に新規メンバーが途中参画した際にもスムーズにオンボーディングできた
テンプレートによってチーム全員がPBIを起票できるようになった
- 特に完成の定義(受け入れ条件)を明文化し、チームの共通認識にできるようになったのは大きい
  - テンプレートに対してはPRを出せるので主体的に提案＆相談できる
- プロダクトオーナーから「アジャイル・スクラムの思想に合うように、仕組みとして誘導できている」というフィードバックをいただけた
GitHub Projectsの使用感
- 前述のテンプレートやPRとの統合などが非常に便利だった
- バックログの管理にGitHub Projectsを利用するのは初めての試みだった
  - これまではGoogle SpreadsheetやNotionなどを利用
    - 本プロジェクトではこれらのツールが利用できないという制約があった

改善したいポイント

Sprint BacklogをPBI単位で扱っている
- 1つのPBIに複数のPRが紐づくケースなどで透明性が下がる
  - PRがマージされた時にPBI(の実体であるIssue)がクローズされてしまうので手動再オープンが必要
    - 参考: Pull RequestをIssueにリンクする
- もう1段階粒度を下げてタスクの単位で扱うべき？
  - ただし、チームの人数等の要素もあるので一概には言えなさそう
微妙に操作しづらい部分が残っている
- ラベルの設定等でGitHubの特定の画面からでないと行えない操作など